Semver Impact of This PR

🟡 Minor (new features)

_{🤖 This preview updates automatically when you update the PR.}

Generated by 🚫 dangerJS against 975a1b4

Codecov Report

❌ Patch coverage is 38.18182% with 136 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.167%. Comparing base (7d833a3) to head (975a1b4).
✅ All tests successful. No failed tests found.

@@              Coverage Diff              @@
##              main     #7598       +/-   ##
=============================================
- Coverage   85.518%   85.167%   -0.352%     
=============================================
  Files          487       494        +7     
  Lines        29659     29880      +221     
  Branches     12896     12889        -7     
=============================================
+ Hits         25364     25448       +84     
- Misses        4244      4382      +138     
+ Partials        51        50        -1     

@sentry review

📲 Install Builds

iOS

⚙️ sentry-cocoa Build Distribution Settings

Performance metrics 🚀

Sentry Build Distribution

Sentry Build Distribution

Thanks for the feedback @noahsmartin, I hope I can give more context like this.

As written the PR doesn't really implement what was proposed in the issue.

I believe you and me have to different takes on the whole topic of building an Objective-C SDK.

The goal of this PR is introducing an Objective-C SDK which wraps our existing Swift+ObjC SDK, to make our Swift-only features available to ObjC too and so we eventually can do breaking changes when turning it into a mostly-Swift SDK.

By asking SDK users to switch from Sentry to SentryObjC they can continue using the SDK from Objective-C, while we can do breaking-change migration, e.g. drop @objc in our Swift+ObjC SDK further down the line (in major releases).

As Objective-C is the past and Swift is the future, my approach sets focus on refactoring the main SDK to Swift, but still offering an (backwards-compatibility) adapter for Objective-C++ projects.

The referenced issue (#6342) shows the objc version of the SDK starts with import Sentry.

I believe this was already discovered and discussed in this PR comment.

I originally built this wrapper SDK to use the same naming too, so it's a direct drop-in replacement. I assumed that the embedded Sentry.framework would be internal only, but both export a class with the same ObjC runtime name which could cause duplicate class conflicts at runtime:

• SentryObjC.framework/SentryObjC: _OBJC_CLASS_$_SentrySDK is the ObjC class from SentrySDK.m
• SentryObjC.framework/Frameworks/Sentry.framework/Sentry: _OBJC_CLASS_$__TtC6Sentry9SentrySDK is the Swift class, mangled symbol, but registers as SentrySDK in the ObjC runtime via @objc

Since SentryObjC is the new SDK, I renamed its class to SentryObjcSDK to avoid the collision.

What this PR does though is something quite different, it introduces a new target that compiles the same source files as the current SDK but with different settings.

This claim is only partially true, because it introduces three new targets (SentryObjC, SentryObjCBridge, SentryObjCTypes) but each with their own files, and it only reuses some of the public headers of the base SDK to deduplicate code.

What the PR actually does is create a pure Objective-C wrapper layer around the existing Swift SDK. The new code acts as a facade/bridge so that ObjC/ObjC++ consumers who can't use Clang modules can still access the full SDK API. The new targets depend on the existing SDK but don't recompile it, they call into it via @objc bridge methods and re-export its existing pure-ObjC headers.

IMO this is going to be much more difficult to maintain than what I proposed, and in particular make it harder to migrate more of the SDK to Swift.

The maintenance overhead is real, I agree with you there, especially with the hand-written ObjC headers that need to stay in sync with the Swift SDK. But the alternative proposal would face the same bridging complexity for any Swift-only type (structs, enums with associated values, generics). The Metrics API, Logger API, and SentryAttributeContent all require manual ObjC-compatible wrappers regardless of architecture.

Regarding making it harder to migrate, I must disagree, as my approach decouples ObjC consumers from the internal SDK implementation as described above. If we migrate an internal ObjC type to a Swift struct or enum, only the bridge mapping code needs updating, the consumer-facing ObjC headers don't change.

An ObjC wrapper SDK would involve 0 changes to existing code files (objc and swift files) and just add one new target to the Package.swift file (SentryObjC - with a dependency on SentrySPM).

I have to disagree. The Metrics API is written in pure Swift using structs and generics. It is not compatible with Objective-C and will never be, hence the bridging logic which introduces an Objective-C compatible API. This is the main reason why we are building an Objective-C SDK right now, because sentry-unreal needs it.

I would really encourage trying this option since it will make long term maintenance much easier. This PR entangles the two distributions (swift public API and ObjC API) and my suggestion separates these two concerns into distinct layers where the ObjC API builds on the Swift API.

I don't believe this is is correct with regards to this pull request.

We are only reusing the public ObjC headers to reduce code duplication. We use @objc(SentryX) annotations to pin the ObjC runtime name so that the hand-written headers in Sentry resolve correctly at link time. They don't constraint future Swift refactoring as we can rename them in Swift and migrate to the ObjC SDK if necessary.

A layered approach like that with a clear boundary between the two is usually easier to work with than try to support two modes like this PR is doing.

My architecture is also creating two distinct layers (with a helper layer in-between): an outer Objective-C SDK wrapping a bridging layer wrapping the Swift(+ObjC) SDK. The boundary is enforced at the module level when SentryObjCBridge imports the SDK as an external dependency, and SentryObjC's .m files only see the bridge through a typed forward declaration. Changes to SDK internals that don't affect the @objc-exposed surface do not produce changes in the wrapper layer. It is not two modes of the same SDK.

I hope this clear things up and that this is not blocking a soonish merge and release.

🚨 Detected changes in high risk code 🚨

High-risk code can easily blow up and is hard to test. We had severe bugs in the past. Be extra careful when changing these files, and have an extra careful look at these:

• .github/file-filters.yml

Thanks @philprime I believe we are in alignment with all the technical points it's just the public API and some subjective decisions around architecture that we don't have the same opinions on. Concretely here is how I see the differences in our approach:

My proposal is to have a wrapper SDK that only exposes an objc API. The architecture would be like this:

┌─────────────────────────────────────────────┐
│ SentryObjC                                  │
│                                             │
│ Public interface: Objective-C headers only  │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ SentryObjCCompat                            │
│                                             │
│ Public interface: Swift module              │
│                 + generated ObjC header     │
└──────────────────────┬──────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────┐
│ Sentry                                     │
│                                             │
│ Public interface: Swift module only         │
└─────────────────────────────────────────────┘

In reality the Sentry target currently contains a mix of ObjC and Swift but the other two would be added and we would slowly move towards Sentry being unencumbered by ObjC code (metrics is an example of this).
Even more concretely, my proposal is to add a new library to the Package.swift like this:

.library(name: "SentryObjC", targets: ["SentryObjC"])

And targets like this:

    .target(
        name: "SentryObjCCompat",
        dependencies: ["SentrySwift"],
        path: "Sources/SentryObjCCompat",
        publicHeadersPath: "Public",
    .target(
        name: "SentryObjC",
        dependencies: ["SentryObjCCompat"],
        path: "Sources/SentryObjC",
        publicHeadersPath: "Public",
    )

Your proposal does not include a "wrapper" SDK in the traditional sense. It does not wrap the existing SDK, it creates a new library that includes the existing targets (seen in your changes to Package.swift). It also would create a new "mode" of compiling the SDK where the module name would be changed to SentryObjC and this SentryObjC would include both public Swift and ObjC code. You can see this by your changes to the files in Sentry/Public, which now need different imports because the same file is being compiled with different names.This is a materially different public API than the ObjC only wrapper I am proposing.

These are different approaches to solve the same problem. However, I would suggest that the method I'm proposing would be easier to understand (in fact it sounds a lot like what you proposed in the PR description), easier to maintain, and easier for users. The key technical differences would be that my proposal is entirely a wrapper - no changes would be made to existing source files. You could validate this by making my proposal in an entirely new GitHub repo, the resulting framework would be identical to the one you'd make if you implemented my proposal in this repo. I am not proposing a new repo (too much maintenance burden). Rather just a thought experiment to demonstrate some clear separation of concerns. This is why I believe (subjectively) that my proposal would be easier, it provides clear boundaries between systems which generally makes it easier to work with the codebase.

I would defer to @itaybre and @philprime to evaluate the subjective pros/cons of these approaches. All I ask that if we go with the library that provides both objc and swift targets in one, we keep #6342 open as a feature request to provide a target that only has publicly visible objc code, with no swift module and no auto-generated objc code from swift @objc annotations.